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?
Mike, forgive me for going on without responding to your initial
question. FWIW, I guess I'd say if your intent is to fill out those
objects eventually - you really do intend those objects to supply each
resolution, I'd go with the 'dummy' approach that Paul described,
especially with external datastreams. But if you really have a
diversity of content resolution-wise that will remain so, I'd be
inclined to formalize it with different cmodels like Scott's scenario.
- Bill
On Jan 26, 2009, at 1:59 PM, 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
Bill Parod
Northwestern University Library
Northwestern University
[email protected]
847 491 5368
------------------------------------------------------------------------------
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
