Hello,

I'm working on a more extensible PREMISE schema right now and just
discovered the same error (No. 1) in Bronwyn's comments. I have a few
more comments embeded below in the discussion and would appreciate very
much your feedbacks.

Thanks,

Zhiwu Xie

Graduate Research Assistant
Research Library
Los Alamos National Lab

On Wed, 2006-01-25 at 14:32, Rebecca S. Guenther wrote:
> On Wed, 25 Jan 2006, Priscilla Caplan wrote:
>
> > Here are my first thoughts, but I hope other PREMISers can chime in to help.
> >
> > Bronwyn Lee wrote:
> > > 1. For Representations objectCharacteristics is Not Applicable, but
> > > significantProperties, within the container ObjectCharacteristics, is
> > > Applicable. Shouldn't either objectCharacteristics be Applicable or
> > > significantProperties be Not Applicable?
> >
> > This looks like an error to me, but it seems like a rather large one so
> > I hope I'm wrong. significantProperties should be applicable to the
> > representation, so would have to be moved out from under
> > objectCharacteristics.
>
> Yes, I think indeed this is an error. I remember how difficult we found
> significant properties. We went back and forth on how much it relates to
> format information, which is probably why it ended up in
> objectCharacteristics. But we also decided that it has to be available for
> a representation (the example was an electronic encyclopedia which had
> many files comprising it and significant properties apply). Somehow we
> must have missed the fact that we can't have it under
> objectCharacteristics. That is surprising that we hadn't caught this, but
> I believe that it is an oversight. I suggest that we take it out of
> objectCharacteristics-- or we might want to allow it both under
> objectCharacteristics (if related to a particular format) and also for the
> representation as an element by itself.

In the current schema, allowing significantProperties to reside in both
places may introduce confusions. This would allow a file object having
two significantProperties elements, one directly contained in the object
element, another directly contained in the objectCharacteristics
element.

Is there any significant property a file object would need to express at
the object level on top of the one at the format level?

Actually I have one more comment on the object categories. The data
dictionary implies strongly an hierarchical schema implementation, such
as having an abstract object type then extend/restrict it to get three
or even more different concrete object types, such as FileObject,
BitstreamObject, and RepresentationObject type. But both the data
dictionary and the schema also show strong tendency to treat all
categories of objects uniformly, e.g., allowing the most relaxed
restricitons in order to accomodate all object categories (if not
mandatory in one category, then optional for all), and use
objectCharacteristics rather than formatCharacteristics even though it
does not apply to all objects. I am just wondering if there's a special
reason for this.

If we can adopt a hierachical schema, then the significantProperties can
be handled in the way that it appears at the object level for the
RepresentationObject, but at the format level for BitstreamObject and
FileObject.

>
> >
> > > 2. format is Mandatory while formatDesignation and formatRegistry are
> > > both Optional. Was formatDesignation (which is the container for
> > > formatName) meant to be Mandatory?
> >
> > This is intentional. formatDesignation and formatRegistry are
> > alternatives, so both are technically optional -- you could chose to
> > omit formatDesignation if you were using formatRegistry, and vice versa.
>
> Yes, you have to have one or the other. The usage note says:
> "Either formatDesignation or formatRegistry should be recorded. Both are
> optional, but since format (the container) is mandatory, one of these must
> be used."

Just to clarify, this is one or the other, not one and/or the other,
meaning I can't have both. Am I right?

>
> > > 3. swVersion is Not Repeatable for Representation and Bitstream but is
> > > Repeatable for File. Is this correct?
> >
> > Hm. I looked at earlier drafts of the data dictionary, and in both the
> > review version in February and the public version in March, swVersion is
> > applicable only to Representation and File, and NR for both. Although
> > the definition mentions "version or versions" which implies Repeatable,
> > an email message in my PREMIS archive explains the wording was intended
> > to accomodate the example ">=2.2.0" -- that is, that multiple versions
> > would be represented in a single occurence of the element. My guess is,
> > this ought to be Not Repeatable for File, which is easily corrected in
> > the errata.
>
> Since the container software is applicable for bitstreams and so are the
> other subelements, I imagine that it is also applicable for bitstream. I
> also have earlier versions with not repeatable, so I would stick to that.
> If you needed to repeat it you would use another software container.
>
> I'll add this to the errata on the PREMIS site-- and also that
> significantProperties should be outside the objectCharacteristics
> container. Whether it should be listed at both levels is something to be
> discussed. We haven't done that before, so the question is whether it
> needs to be tied to a particular format at the file level as well as
> separated at the representation level.
>
> Rebecca
>
> >
> > Priscilla
> >
> >
> > >
> > > Regards
> > > Bronwyn Lee
> > > Australian Partnership for Sustainable Repositories
> > > (http://www.apsr.edu.au)
> > > National Library of Australia
> > > Canberra ACT 2600 Australia
> > >
> > >
> >