Jerry and UC-WISE people,
So a CUP is like a pod that unmarshalls on the fly? There's no reason we can't make pods do that themselves. The pod graph is in the pod metadata and so doesn't require unmarshalling the contents. For when you do need the pod contents, we could make pods unmarshall just-in-time. If pods did that, would you still need CUPs? -t On 11/22/06, Jerry Cheung <[EMAIL PROTECTED]> wrote:
For background info on CUPS: http://www.telscenter.org/confluence/display/UCW/CUPS In PAS, it makes sense to glue together all related beans and unmarshal the entire PAS hierarchy in the learner runtime. However, for UC-WISE and CUPS, unmarshalling a curnit could mean unmarshalling an entire semester's worth of content. This doesn't make sense when all we want is only a portion of a curnit. We came up with the idea of Handle's on CUPS to have finer grained control on how much of a hierarchy to build at runtime. A Handle is the metadata and pod-uid that describes a CUP. For example, suppose a curnit root pod references twenty children. Our goal was to prune these children branches by using Handles as a filter of what to fetch and unmarshal from SAIL. First, we fetch and unmarshal the root pod, which gives us a list of Handles of our children. From here, we can filter on the metadata of the Handles and determine which pod-uids to fetch and unmarshal. We repeat this process down to the leaves of the hierarchy. This approach leaves us with a different approach to a 'curnit'. There would be a curnit describing a grouping of Pods containing Handles, and also a curnit describing a grouping of Pods containing the corresponding CUP beans. Now that I think about this more, I feel this might duplicate Pod metadata functionality. The reasoning for Handles is to only fetch the root pod, and the root's children pods. Further pod retrievals would be based on Pod metadata. What about session-specific metadata such as date? It doesn't make sense to have dates on Pods because they are used from semester to semester. This seems like something that belongs in Offering, but we're not sure how to go about it. If Offerings are stored in Pods, and Pod metadata functionality gets implemented, then that's one possibility of where we could store session-specific metadata. Will Offerings also live within Pods? My guess is no since Pods are the unit of reuse of *content*. However, there must be some kind of backend to support an Offering. What would this be? Searching for 'metadata' in the SAIL space of the wiki: "...will be attachable to SAIL entities in any schema. For example, a user will be able to annotate a pod with a LOM field and a Dublin Core field at once." What does 'attachable in any schema' mean? -jerry >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
