Hi First up, my initial proposal was just the factor out the way find the content models for a object into a method, rather than directly querying the relations. This should not in any way change the behaivour of Fedora. This would make ANY approach much simpler to implement later.
After that, yes, I would like some sort of inheritance system to be added. The exact form of this is still unclear. On Wed, 2009-07-08 at 17:41 +0200, Daniel Davis wrote: > 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? To be very clear, what I would like is a way, in the content models, to say "If you have me as a content model, it implies that you also have this other Content model" This statement is really the basis on which inheritance is built. I did expect the models to be assembled at the moment of use, but that was because I did not consider the static approach. > > 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? In the current system, the content models are mixed in before service delivery. I did not expect to change anything about this. I just expected to change the way Fedora determines which content models apply to a object. The mixing approach could actually remain as is. My initial idea was that inheritance could not work without the resource index, as the performance hit would be huge in traversing the graph. The static approach you mention could work. Fedora has a database server, wherein the inheritance graph could be stored. Any change to RELS-EXT in a content model updates this graph, but otherwise it is static. This would allow fast queries for the content models of a object. Regards > > 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
