Good suggestion, thanks. That should go on the list for the next
On Feb 13, 2006, at 10:59 AM, Zhiwu Xie wrote:
> Thanks a lot for the answer. I can see the problem now. Actually
> you may
> want to consider an alternative in the official PREMIS schema that
> requires less maintainence:
> 1. Define an abstract objectType, with neither type attribute nor
> objectCategory element defined at this level
> 2. Define a global objectCategorySimpleType which is basically the
> xs:string type, like the following:
> <xs:simpleType name="objectCategorySimpleType">
> <xs:restriction base="xs:string"></xs:restriction>
> 3. Define three or even more concrete objectType that extend the
> abstract objectType, in which they all have objectCategory elements
> which are defined respectively, although of the above defined
> objectCategorySimpleType, which is basically the xs:string type,
> but fix
> the value to the controlled vocabulary. The following give the
> definition of the fileObjectComplexType as an example:
> <xs:complexType name="fileObjectComplexType">
> <xs:extension base="objectComplexType">
> <xs:element minOccurs="1" maxOccurs="1"
> name="objectCategory" type="objectCategorySimpleType"
> I think this kind of schema structure has a handful of benefits to
> to the PREMIS community:
> First, it eliminates possible confusions introduced in the
> following two
> 1. An object with a "file" type attribute value, but a different
> objectCategory value
> 2. An object with the same type attribute and the objectCategory
> e.g., "representation", but includes an element that is not allowed in
> that type of object, e.g., objectCharacteristics
> Although common sense should not allow the above happen, in
> practice you
> never know. Errors like this happen, either from human or from the
> machines. If the schema does not capture them and allow them
> chances are the errors will be introduced into the system.
> Second, not only this schema follows the objectCategory definition
> as an
> xs:string, but it strictly limits its value when comes to the already
> defined three types of object, file, bitstream, and representation. On
> other hand, if any implementation needs more flexibility, the
> of the extension is already provided. People only need to extend their
> own concrete objectType, mostly by making use of the many globally
> defined types to construct the extension. For any extensions following
> this example, the extended objectCategory should have the "fixed"
> attribute that limit the value to a controlled vocabulary.
> Hope this helps,
> Zhiwu Xie
> Graduate Research Assistant
> Research Library
> Los Alamos National Lab
> On Thu, 2006-02-09 at 10:38, Jerome McDonough wrote:
>>> On Mon, 6 Feb 2006, Zhiwu Xie wrote:
>>>> This is an implementation question.
>>>> In schema v1.1 there's an attribute "type" for the "object"
>>>> Although optional, it's set to enumerate either "file",
>>>> "representation", or "bitstream". I think this attribute is
>>>> because the objectCatgory contains the same information.
>> Well, yes and no. Yes, in that they're intended to convey the same
>> of information, but no, in that objectCategory doesn't insist on the
>> vocabulary established in the PREMIS model, so in practice, someone
>> could put any type of information they wanted in there. My memory of
>> the discussions was that the flexibility in objectCategory was
>> intentional, as
>> people were a bit reluctant to state that everyone in the world
>> had to
>> conform to the PREMIS' group's notion of object categories. So,
>> was left as an open string, in case someone decided they needed
>> in local practice. The type attribute is obviously more constrained,
>> and was
>> included so that there could be a dependable, controlled
>> vocabulary for
>> use between institutions for identifying the category of object.
>>>> Also it hinders further extension, because in case of more object
>>>> categories are needed, this attribute needs to be modified each
>>>> time an
>>>> extension is proposed.
>> That is true, and that is the downside of controlled vocabularies.
>> They do
>> require maintenance. The upside is having a reliable shared
>> between institutions/applications. So, there's a cost/benefit
>> calculation in
>> deciding whether to adopt them. Part of the calculation is the
>> of rapid change. To date, I don't think I've heard anyone say
>> that they
>> need the set of object categories altered or extended, so I don't
>> think it's
>> imposing a particularly great burden to date, particularly given that
>> type attribute's use is optional.
>>>> Even no extension is expected, it still adds unwanted complexity
>>>> to a
>>>> hierarchical schema.
>>>> I'm working on a schema that first defines an
>>>> abstract objectType, then extend it to three or even more different
>>>> types, e.g., fileObjectType, bitstreamObjectType,
>>>> representationObjectType. If we must have this attribute, I'll
>>>> have to
>>>> further restrict the extended types to accommodate this redundant
>> I'm afraid I'm not sure I see your problem. If you're developing
>> your own local application profile schema to support PREMIS,
>> your only real concern is to support the *mandatory* aspects
>> of the PREMIS schema, and the type attribute isn't mandatory.
>> So, what exactly is preventing you from creating an abstract
>> objectType schema which omits the "type" attribute and extends
>> it from there?
>> Jerome McDonough, Asst. Professor
>> Graduate School of Library & Information Science
>> University of Illinois, Urbana-Champaign
>> 501 E. Daniel Street, Room 202
>> Champaign, IL 61820
>> (217) 244-5916
>> [log in to unmask]
Asst. Prof. Jerome McDonough
Graduate School of Library & Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493
Champaign, IL 61820-6211
[log in to unmask]