Print

Print


Good suggestion, thanks.   That should go on the list for the next
version.

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>
> </xs:simpleType>
>
> 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:complexContent>
>     <xs:extension base="objectComplexType">
>       <xs:sequence>
>         ...
>         <xs:element minOccurs="1" maxOccurs="1"
>           name="objectCategory" type="objectCategorySimpleType"
>           fixed="file">
>         </xs:element>
>         ...
>       </xs:sequence>
>     </xs:extension>
>   </xs:complexContent>
> </xs:complexType>
>
> I think this kind of schema structure has a handful of benefits to  
> offer
> to the PREMIS community:
>
> First, it eliminates possible confusions introduced in the  
> following two
> ways:
>
> 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  
> values,
> 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  
> validated,
> 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  
> structure
> 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"  
>>>> element.
>>>> Although optional, it's set to enumerate either "file",
>>>> "representation", or "bitstream". I think this attribute is  
>>>> redundant
>>>> because the objectCatgory contains the same information.
>>>>
>>
>> Well, yes and no.  Yes, in that they're intended to convey the same
>> *type*
>> of information, but no, in that objectCategory doesn't insist on the
>> controlled
>> 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,
>> objectCategory
>> was left as an open string, in case someone decided they needed
>> flexibilty
>> 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  
>> vocabulary
>> between institutions/applications.  So, there's a cost/benefit
>> calculation in
>> deciding whether to adopt them.  Part of the calculation is the
>> likelihood
>> 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
>> the
>> 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
>>>> attribute.
>>>>
>>
>> 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
(217) 244-5916
[log in to unmask]