I must have mis-spoken in that I do believe the the "mix-in / trait" model is the most practical for the Fedora pattern. By static, I only meant the creation of the contents of a given model expression datastream. In use by services, the mix-in (aggregation) and service binding needs to be fully dynamic. I am wondering if Asger is asking the question of whether permitting having the "mixed-in" content models be derivations/extensions of other content models using some approach (like inheritance)? Are the model expressions assembled at the moment of use?
For simplicity and performance reasons, I am concerned with trying dynamically follow a chain of objects to assemble a model expression along a given inheritance path. There would be a lot of latency caused by the object traversal. Could the tranversal be done ahead of time and the combined model expression be stored in a datastream in a CModel object adjacent to a Data Object with asserting the "hasModel" relationship? In Asger's proposal, are the models from different chains subsequently "mixed-in" (aggregated) at the last step before the Fedora Repo uses them particularly for service delivery? Content models need information to use in object composition, validation, and service binding (does anyone have ideas for other stuff that should be in the model). One question is whether the information is contained in one conceptually comprehensive model or divided up in pieces. If divided up where should the model pieces reside (different DOs)? And what are the rules for combining them in a distributed, Web-like architecture? Pre-ingest composition and off-line validation are not so sensitive to performance. However, dynamic service delivery and on-line validation is very sensitive. I don't think inheritance and "mix-in" approaches are mutually exclusive approaches for Fedora but we need a good debate to see how they play out. And using static creation of a model expression by gathering pieces in an inheritance chain, storing the result in a CModel, then using a "mix-in" of one or more model expressions from adjacent CModels in the last dynamic aggregration may be a way to combine both approaches. This note is already too long so I would like to start a separate thread on validation services if it is OK with you folks. Daniel W. Davis Fedora Commons http://fedora-commons.org [email protected] Benjamin Armintor wrote: > The Fedora 3 CMA, as it stands, seems far closer to a mix-in or trait > model of inheritance than a static, superclass-based one. But it is > incomplete here, as well, since there is no conflict resolution (that > I know of) for conflicting service deployments. Incorporating an > actual inheritance structure into the content models would increase > the potential for collisions, a la multiple static inheritance in > other languages. > > I think the three-pronged summary of content models Daniel offers is > useful. It also makes me wary that a static approach to inheritance > moves the focus of content models towards object composition, and I'm > not sure that should be prioritized over service binding. > > I suppose my view of objects tends to be service-oriented, since my > reaction to Daniel's comments about plug-ins was first to think object > validation is a good plug-in candidate, and the second was to think > that perhaps the validation should be bundled into services exposed by > another object in the repository... > > - Ben > > On Wed, Jul 8, 2009 at 9:20 AM, Daniel Davis<[email protected]> wrote: > >> I think an approach which is static should be considered. In this >> approach, the content models of superclasses are incorporated into the >> content models which are stored in objects immediately adjacent to the >> data object prior to use (a priori). In some ways this is ORE inspired >> where we confine ourselves to aggregations and avoid having to solve >> graph closure problems in real time. Using this approach, only one >> operation is needed to obtain each adjacent content models which >> contains all the inherited information from their superclasses (which >> can be combined into one general operation to grab all the models as >> suggested by Asger). Using this approach dramatically reduces latency >> for getting inheritance information especially if we begin to consider >> federation where content model objects (and service definitions) may not >> be co-located within the same Fedora repo instance. Update of the >> adjacent content models happens only when a change occurs to the >> superclasses. This approach would facilitate operation of Fedora >> without requiring the use of a triple-store. >> >> To make the services (disseminations) fast an internal cacheing >> mechanism is currently used. Its operation needs to be considered in >> the design. Also, content models (with service definitions) serve (or >> should serve) several purposes. The first is service binding (most >> latency sensitive), second validation (care needs to exercised here >> regarding what operations are appropriate within the repository and what >> can be done externally), and third object construction (which can >> substantially be done outside the repository). When and where these >> functions happen need to be considered. >> >> If possible, adding additional methods can be done by extending system >> content models and service definitions putting the operation on the >> object rather than extending the APIs. >> >> This note is just discussion, I am not sure which is the best way to >> support inheritance---a static or dynamic approach, with or without >> triple-store assistance, and where to put the related methods. But I >> certainly support figuring out how to do inheritance. Please consider >> when the inheritance occurs, performance impact and how to mitigate >> latency concerns, and how to minimize code changes. In particular, I >> think the Fedora Repo needs to move to a microkernel architecture where >> as many functions as possible are pushed into plug-ins or loosely >> coupled service bindings. I hope this helps provoke additional discussion. >> >> Daniel W. Davis >> http://fedora-commons.org >> [email protected] >> >> >> >> >> Asger Blekinge-Rasmussen wrote: >> >>> Hi >>> >>> We, with the Enhanced Content Models, want to support content model >>> inheritance. Due to the freedom for Fedora Content Models we can easily >>> define a inheritance relation between content models, and inheritance is >>> thus supported. No problem there. >>> >>> But only applications that understand this inheritance relation, can use >>> this inheritance system. And, more importantly, disseminator bindings do >>> not understand any sort of inheritance. >>> >>> I have checked the Fedora code. There are 32 usages of the reference >>> Constants.MODEL.HAS_MODEL, to get the content models of a object. To me, >>> this feels like something that should be collected in a general method, >>> like getContentModels(pid) or the like. >>> >>> I would like to collect these usages, and make this general method, but >>> only if work like this would be interesting to Fedora. This is not >>> something that I would like to maintain myself, rather it should be >>> integrated into the Trunk when the code have been approved. >>> >>> If this is a feature the Fedora Developers would like, I will start work >>> on it soon. >>> >>> Regards >>> >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited time, >>> vendors submitting new applications to BlackBerry App World(TM) will have >>> the opportunity to enter the BlackBerry Developer Challenge. See full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> Fedora-commons-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >>> >>> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> >> ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
