 |
 |
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]