TNS Internal:EduPakArchRoadmap/BoulderRequirements

From NSDLWiki

Coming out of the latter half of Aaron's meeting in Boulder (10/5-10/8), we discussed and gathered some observations upcoming requirements for EduPak from DLS. The requirements stem from plans for learning apps and satisfying TNS requirements of serving pathways' needs.

Requirements

Fix Collections

EduPak is supposed to be a framework for rapid development of apps using common tools and practices. The NDR model and API have proven to be too complex for apps to interface with directly. Ultimately, the suggestion arose that we may need a new, unambiguous collection API for our apps to work with.

We discussed the use cases and requirements for such an API at length, and have a separate page detailing a collections API

This API would likely be all an application would need to inderface with the NDR, so the current line of thinking would be that the NDR API would be deprecated as far as developing apps goes, and instead would be used by infrastructure that requires low-level to objects and datastreams. The NDR model would be hidden to the apps, and would adopt a more hidden, administrative role.

Annotations

Support for annotations was identified as critical for developing learning apps, and supporting new use cases.

Annotations, in the sense of DLS applications and future learning apps, are defined to be external enhancements/additions to metadata records. This is entirely different from the NDR's conception of annotation. The NDR's conception of annotation is a resource containing content that annotates/augments the content of another resource.

Some specific use cases for annotations of the DLS flavor include:

• The AAAS will work with various pathways by enhancing their metadata with alignments to benchmarks. These alignments are to be intellectually attributed to the AAAS, but viewed as a part of that individual pathway's metadata record. Thus, if a specific pathway were building a portal that searches/displays that pathway's resources, these resources would be associated with BOTH the native metadata catalogued by the pathway AND the enhancements that the AAAS provided for that pathway ONLY.
• The state of Indiana selects records from the NSDL that are cataloged particularly well, and decides to enhance this data with their own state standards. They then wish to export this annotated data from the repository and use it somehow
• The CCS uses the annotation framework heavily, and is considered a learning app. New learning apps, or extensions to existing learning apps will likely use the same patterns. Annotation support would be required for them to be compatible with the repository.

Thus, the NDR is required to support annotations of the DLS flavor. Existing NDR-flavor annotations have no place in any future plans.

JMS

JMS must available for updating indexes in almost real time, as well as supporting low-level repository services such as OAI. Fedora 3 natively supports creating JMS messages in response to updates. While Fedora contains its own ActiveMQ JMS service, a real production setup would need an external JMS provider in order to provide the possibility for durable messages refardless of Fedora's up/down status. In addition, apps have the option of using this message bus for creating their own messages, or subscribing to the messages of another app.

Security

The stark reality is that some pathways do not wish to share their highly-curated data with the rest of the world. In order to accommodate them in the repository in their native format, the repository (or some other mechanism) needs to be able to authorize reads to protected resources. Security is also relevant to apps such as CCS, which need to store potentially private documents. If they are to be able to use the production repository, it must be possible to secure resources.