DefiningImageAccess/Project/Pathways
From ImageWeb
| DefiningImageAccess/Project/Pathways | |
|---|---|
| homepage:=http://www.infosci.cornell.edu/pathways/}} | |
| [[has sub-project::{{{Subproject}}}]]}} | |
| sub-project of::DefiningImageAccess/Project/ORE}} | |
| [[start date:={{{Start date}}}]]}} | |
| [[end date:={{{End date}}}]]}} | |
| Status:=Completed}} | |
| JISCProject:=false}} | |
| [[Image Materials:={{{ImageMaterials}}}]]}} | |
| Focus:=Repository interoperability}} | |
| [[Publishes::{{{Publishes}}}]]}} | |
| [[References::{{{References}}}]]}} | |
| [[Uses::{{{Uses}}}]]}} | |
| [[Creates::{{{Creates}}}]]}} | |
| [[Partner::{{{Partner}}}]]}} | |
| [[Contact::{{{Contact}}}]]}} | |
Pathways Project
- http://www.infosci.cornell.edu/pathways/ - Lifecycles for Information Integration in Distributed Scholarly Communication. Los Alamos National Laboratory and Cornell University.
The Pathways project was instigated to develop broadly applicable models and protocols to support a loosely-coupled, highly distributed, interoperable scholarly communication system. Work to date has resulted in a number of publications (http://www.infosci.cornell.edu/pathways/#publications) and to a significant new effort, Object Reuse and Exchange (ORE) ... ORE intends to take the results of Pathways work as a starting point for the development of interoperability standards to facilitate the efficient dissemination of content.
"Cross-repository interoperability must be augmented to support the many workflows and value-chains involved in scholarly communication. This will not be achieved through the promotion of single repository architecture or content representation, but instead requires an interoperability framework to connect the many heterogeneous systems that will exist." -- http://arxiv.org/abs/cs/0610031. This is significant: the Pathways goal, also stated in papers from this project, is to provide a service oriented overlay that can abstract away from the details of digital object representation, creating interoperable systems that do not depend on on asset transfer.
"The process model work will investigate the use of functional programming principles to enable easy composition of distributed processes, or pathways, through which scientific results flow". (As a proponent of functional programming, I really like this bit.)
It appears that the Pathways approach is to create an overlay, or virtual publication ("we describe an experiment that demonstrates how the proposed infrastructure can be deployed to implement the workflow involved in the creation of an overlay journal over several different repository systems (Fedora, aDORe, DSpace and arXiv)"), this being philosophically different to our data webs approach (which aims to expose the originals rather than present an overlay), but many of the problems faced are likely to be similar.
Publications:
- http://www.dlib.org/dlib/october06/vandesompel/10vandesompel.html - An Interoperable Fabric for Scholarly Value Chains - an introduction to the i8deas and concepts
- http://arxiv.org/abs/cs/0610031 - Pathways: Augmenting interoperability across scholarly repositories - a more detailed description of the technical framework.
Notwithstanding the philosophical difference noted above, more detailed examination of the publications suggests there is nothing in the Pathways approach that precludes its use in a data web. The underlying Pathways philosophy is very similar to that which has given rise to our plans for data webs. There are three key elements:
- an abstract model for an arbitrary digital object, that articulates composite objects, lineage (part of provenance), possibly multiple data streams for representing an object (or parts), global or repository-local object identification, intended persistence information. This model is very simple, yet flexible and deeply researched. The authors envisage that it might be used as a core that can be extended in situations where higher levels of interoperability are required.
- three simple abstract interfaces covering essential repository interactions: obtain, harvest and put.
- shared registries for accessing information about services, data formats and semantics. The project notes indicate a focus on managed repositories rather than the open web, and specific repositories seem easy enough to deploy for such a scenario. In our data webs work, we also wish to incorporate the wider web (e.g. local workgroup data publications), but I think the registry issue might be finessed for these by using http: URIs, and simply using the Web as a fallback registry.
Although the Pathways model is conceived to be technology independent, trial implementations make extensive use of RDF, so many opf the structures are already in the form we anticipate for our data webs work. An important aspect of this work is that if focuses on machine accessibulity of information, which can be used as a basis for building new (overlay) services on existing repositories.
In conclusion, I think we should probably aim to build our data webs work on the Pathways model unless and until some specific problems are encountered. I would be surprised if there are any such that cannot be overcome. In this way, we can hope to build upon implementation work that is based on the Pathways model (e.g. see the ORE project), and maybe can feed proposals back to the body of work that is building on the Pathways foundation.
