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
