Hi If you built what I call a "call-back disseminator", there is an easy solution to the problem.
A callback disseminator is a webservice that, as part of disseminating a datastream, performs calls to Fedora to get the contents of other objects. The Fedora architecture does not exactly love this kind of thing, but it is supremely usable and does work. If you had such a beast, you could separate the optional components (like thumbs) into another object. So you would have Image objects with an optional hasThumb relation to Thumb objects. The getThumb disseminator on Image would check for this relation, and grap the data (or call a disseminator) from the Thumb object if there, and if no object return some default or error. With this design you can add the contents as you get them, without ever violating the content models. Regards On Mon, 2009-01-26 at 20:59 +0100, Paul Hammer wrote: > Mike, > > An alternative to creating complexities in the object model is to > create "Dummy" objects that will stand in for the final object until > such time as it is ready. The exception handlers in the > administrative tools can be set to attach the "Image not available" > datastream, if the real file is undefined or unavailable. Indexing > the collection so that all of the incomplete objects are easy to find > should simplify the process of identifying objects with dummy images > attached to them. Dummy data streams could also be defined as an > external reference rather than storing thousands of instances of the > same image in the repository. Setting up some sort of candidate > status to flag incomplete records can be beneficial too. > > It is certainly a matter of taste and style but I would opt for this > method rather than creating a separate object model for each > permutation of an incomplete record. It pretty much boils down to > whether you want to maintain a rich set of object model descriptions > or whether you want to chase down dummy object references. Neither > prospect is particularly attractive or easy in a large repository. > > Paul Hammer > Database Administrator > University of Maryland > McKeldin Library > 3199 > Voice: 301-314-7963 > [email protected] > > Scott Prater wrote: > > According to the Content Model Architecture docs, every digital object > > that is linked to a Content Model must have, at a minimum, the > > datastreams defined in the Content Model. Here are two approaches you > > could take: > > > > 1. Create a content model for every variation of image you have. If > > there are not too many variations, this is a relatively cheap way to go: > > > > ImagesWithThumbAndLowRes, ImagesWithThumbAndHiRes, ImagesWithThumbAndLowRes > > > > and then just link your object to the appropriate model. Each one of > > these Content Models would list all the datastreams that the digital > > object should have. > > > > 2. Create three content models: ImagesWithThumb, ImagesWithLowRes, and > > ImagesWithHiRes. Then link your object to all the applicable Content > > Models as appropriate. Each Content Model would list just one > > datastream ("thumb", "lowres", etc.) This means more Content Models to > > keep track of in your digital objects, but allows for more flexible > > combinations. > > > > Ideally, (maybe in a future release of Fedora?) Content Models would > > support inheritance, so you could have a base Content Model "Image", > > then a subclass Content Model "ImageWithThumb". "ImageWithThumb" would > > inherit all the service definitions and datastream constraints defined > > in "Image". But we're not there yet. > > > > -- Scott > > > > Park, Michael wrote: > > > > > Hi, > > > > > > > > > > > > I am creating a Content Model for an image. It will have thumbnail, > > > master, lowres and highres datastreams. How can I handle times when I > > > will not have every one of those datastreams for the object? Does > > > Fedora allow this? > > > > > > > > > > > > Thanks, > > > > > > Mike > > > > > > > > > ------------------------------------------------------------------------ > > > > > > ------------------------------------------------------------------------------ > > > 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 > > > > > > > > > > > > -- > Paul Hammer > Database Administrator > University of Maryland > McKeldin Library > 3199 > Voice: 301-314-7963 > [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
