1. Update Exchange with Provenance Schemas are related by GLAV schema mappings (tgds) : M4: Domain_Ref(SrcID, 'Interpro', ITAcc), Entry2Meth(ITAcc, DBAcc, DB) → Domain_Ref(SrcID, DB, DBAcc) M5: Domain_Ref(SrcID, 'Interpro', ITAcc), Interpro2Go(ITAcc, goID), Term(_, goName, goID) → GoTerm(goID, goName) Provenance encodes all derivations of each tuple through the schema mappings Facilitating Collaborative Data Sharing Application Scientific research groups (e.g., biologists) maintain independent but related warehouses, where they store and continuously revise their data Each group wants to incorporate and curate all relevant data from other warehouses that they trust, requiring: Translation of data between different schemas, as it is updated Reconciliation of conflicts among data from different sources Collaborative data sharing addresses these needs, facilitating exchange of data among autonomous sites. Setting Each participant has a local database instance that they query and update, as well as: Schema mappings specifying data correspondences Trust conditions over sources and mappings, specifying how to filter and prioritize others’ updates Orchestra Operation A site periodically publishes the updates it wants to share The site may also import updates from elsewhere, using: 1.Update exchange, which converts all trusted updates into the requestor’s schema, using schema mappings 2.Reconciliation, which resolves any conflicts among the trusted updates using trust priorities – resulting in a consistent instance As part of the process, sites maintain provenance information, and use it to: Evaluate trust conditions and priorities Maintain local instances incrementally Reconciliation Citations T.J. Green, G. Karvounarakis, Z. Ives, V. Tannen, “Update Exchange with Mappings and Provenance,” submitted for publication, 2007. T.J. Green, G. Karvounarakis, V. Tannen, “Provenance Semirings,” PODS 2007. N. Taylor and Z. Ives, “Reconciling while Tolerating Disagreement in Collaborative Data Sharing,” SIGMOD 2006. Ives et al., “O RCHESTRA : Rapid, Collaborative Sharing of Dynamic Data,” CIDR 2005. Acknowledgments Work funded in part by NSF IIS-0477972 and IIS-0513778 For More Information http://www.cis.upenn.edu/~zives/orchestra Todd J. Green, Grigoris Karvounarakis, Nicholas E. Taylor, Olivier Biton, Zachary G. Ives, Val Tannen University of Pennsylvania (A,1)  (Q,1) +( A,1) +( B,2) (A,1)  (R,1)  +( B,3) (R,1)  (S,1) Accepted Deferred Rejected All transactions are trusted at the same priority. First attribute is a key for the relation.  +( Z,4) Participant reconciles at this point Conflict: Different changes to same tuple  +( Q,5) Transaction modifies data from an earlier transaction Conflicts with deferred transaction Depends on deferred transaction Conflicts with accepted transaction Time: earlier → later PCBI PLASMODB Domain_Ref src_id,db,dbacc GoTerm goID,go_name M4 M5 EBI INTERPRO Interpro2Go itacc,goid Entry2Meth entry_ac,method_ac,db GO GOTERM Term id,name,acc nodes indicate updates made by the local site