Another approach is to use a single schema to define the elements, but
to also define wrapper elements for each objectCategory, in the same
schema or one or more separate schemas, that ref those basic elements.
The refs within <representationMetadata> etc. could then specify
independently for each level whether elements are required. This is what
we do locally for our VRA-Core like schema to handle differing
requirements for a common set of elements used within wrappers for
groups, works, and surrogates.

The downside in the PREMIS case is for people who find it problematic to
carry the wrapper. Not sure why, but I guess it could be.

--Robin

On Wed, 20 Jul 2005, Priscilla Caplan wrote:

> The idea of separate schema for the different types of objects is real
> interesting.   We too are concerned with the (lack of) utility of very
> loose schema validation.  I'm not sure what the best solution is.  I
> think the Implementors should not feel bound to use the schema provided
> but feel free to experiment with different ways of expressing the PREMIS
> semantics.
>
> Priscilla Caplan
> Florida Center for Library Automation
>
> Ryan Chute wrote:
> > Hi Rebecca,
> >
> > Thank you for your feedback.  I understand the necessary
> > Representation/File/Bitstream mandatory element variances, but the use
> > of a single schema for all object categories introduces significant
> > complexities. Provided the Data Dictionary is the authoritative
> > description, a processing application will have to perform additional
> > validation to ensure Premis validity. Why was the decision made to use a
> > single schema to handle varied mandatory elements for each
> > objectCategory?  Although a bit more to manage, the creation of
> > Object-Representation.xsd, Object-File.xsd, Object-Bitstream.xsd schemas
> > would help ensure Premis standardization.  Alternatively, a slight
> > loosening of the mandatory elements for the File objectCategory would
> > allow File/Bitstream to share a single schema.  Any information you can
> > provide regarding this topic is much appreciated.
> >
> > Thanks,
> > Ryan
> >
> >
> > Rebecca S. Guenther wrote:
> >
> >> On Mon, 11 Jul 2005, Ryan Chute wrote:
> >>
> >>
> >>
> >>> Hi all,
> >>>
> >>> Working with the PREMIS Data Dictionary and the Object Schema, we've
> >>> noticed a number of discrepancies between the two; primarily pertaining
> >>> to mandatory elements.  I was hoping the list could provide a bit of
> >>> clarification as to what is the precise definition of a valid PREMIS
> >>> object.
> >>>
> >>> 1. Why inconsistent mandatory element definitions (Object-v1-0.xsd vs.
> >>> Data Dictionary)?
> >>>
> >>> There are a number of elements which are mandatory according to the data
> >>> dictionary, but not by the object schema (e.g. preservationLevel,
> >>> objectCharacteristics, compositionLevel, format, storage).  This
> >>> introduces a second question:
> >>>
> >>>
> >>
> >> In the schema, the only things that are mandatory are those that are
> >> mandatory at all levels in the data dictionary. In the case of
> >> subelements
> >> (that have a container element above them) they are only truly mandatory
> >> if the container element exists.
> >>
> >> So in the case of preservationLevel, it is applicable for representation
> >> and file but not for bitstream. objectCharacteristics is applicable for
> >> file and bitstream but not for representation. Same for compositionLevel
> >> (which is also a subelement of objectCharacteristics, so wouldn't apply
> >> unless the latter exists) as well as format and storage.
> >>
> >> This is because we can expect to have PREMIS metadata at any of the 3
> >> levels so we can't make it mandatory in the schema if it isn't applicable
> >> at all levels, and we note that distinction in the data dictionary. So
> >> the
> >> 2 have to work together.
> >>
> >>
> >>
> >>> 2. What constitutes a valid Premis Object (Object-v1-0.xsd vs. Data
> >>> Dictionary)?
> >>>
> >>> Issue 1 poses the question: "If an xml document validates against the
> >>> object schema, is it truly a valid premis object?"  In other words, if a
> >>> record validates against the object schema, but does not contain either
> >>> preservationLevel or storage elements, is it a legitimate premis
> >>> object?  What definition of a premis element should be observed?
> >>>
> >>>
> >>
> >> So is this still a question? I would think that to validate an object
> >> would require more than just validating against the schema if it were to
> >> consider the levels. It would have to validate that the semantic unit
> >> exists if it were at a given level (and we do have the semantic unit
> >> "objectCategory" which designates the level).
> >>
> >> Rebecca
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> ^^  Rebecca S. Guenther                                   ^^
> >> ^^  Senior Networking and Standards Specialist            ^^
> >> ^^  Network Development and MARC Standards Office         ^^
> >> ^^  1st and Independence Ave. SE                          ^^
> >> ^^  Library of Congress                                   ^^
> >> ^^  Washington, DC 20540-4402                             ^^
> >> ^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
> >> ^^  [log in to unmask]                                          ^^
> >> ^^                                                        ^^
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> >
> >>
> >>
> >>> We'd like to ensure we're implementing a standards compliant premis
> >>> approach.
> >>>
> >>> Thanks,
> >>> Ryan Chute
> >>> Digital Library Research & Prototyping
> >>> Los Alamos National Laboratory, Research Library
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
>

--
Robin Wendler  ........................     work  (617) 495-3724
Office for Information Systems  .......     fax   (617) 495-0491
Harvard University Library  ...........     [log in to unmask]
Cambridge, MA, USA 02138  .............