Hi, Bill -- Yes, my sense reading the Fedora docs and wiki is that the CDMA is designed primarily to enable Content Model reuse and sharing, by making them as modular as possible. This, I think, is the whole point of the mix-in idea, the ability to subscribe a digital object model to as many Content Models as is necessary to adequately describe the object and its behaviors, but no more. One of the great things about this mix-in approach is that someone else (such as you) could take my objects, import them, and add/override more Content Models to them to refine them even further.
One danger we've discussed here, though, is what happens when Content Models begin to step on each other. We haven't tested this out yet, but what happens if Content Model A implements foo(), and Content Model B also implements foo(), and digital object Bar is a member of both A and B? Which implementation of foo() gets executed? Or, in the case of datastreams, what happens if Content Model A says the object must contain a datastream FOO of mime type text/xml, and Content Model B says the object must contain a datastream FOO of mime type text/html? Which (if any) constraint is applied to digital object Bar? A wide, rich plethora of atomistic Content Models can open yourself up to that kind of confusion. That would be something that would need to be taken into account also when designing a shareable Content Model registry -- anyone who implements your Content Models will need to know, preferably up front, if your Content Models are going to overlap with theirs. -- Scott Bill Parod wrote: > This has been a real interesting discussion. It brings up a design > principle I've wondered about with CMDA: Does one view cmodels for > data integrity or service readiness? That is, if you're using cmodels to > enforce object completeness (data integrity), you might be inclined to > express rich cmodels that thoroughly describe complex objects. However, > if your goal is to maximize your objects' reusability (service > readiness), you might be inclined to express multiple cmodels that are > simpler with minimum datastream requirements so that a given object is > more likely to match requirements for more services. I've been tending > toward the latter approach since CMDA. I think this is in the spirit of > what Scott suggested, (is that right, Scott?) but with premium on > satisfying likely service opportunities. > > Of course, one can go both ways, declaring complex cmodels for > integrity, profiling, or more demanding service requirements. And also > break those out simply to enable contractual promiscuity. So maybe this > is a non-issue.:) But if there's community potential for cmodel and > service registries, it might be good to map this out a bit and see where > there are natural cmodel/service agreements/opportunities. Are there > other trade-offs to consider? How are others approaching this? -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
