We at NLA have been looking more closely at relationships. I noticed the problem of relatedEventIdentifcation being mandatory in relationship, but found the email in the PIG list archive that says the obligation needs to be changed (Rebecca's message to the PIG list dated 1 July 2005). I have a couple of other comments to make about relationships in the data dictionary. STRUCTURAL RELATIONSHIPS Under relationshipType on page 2-62 it says "structural=a relationship between parts of an object". That much is clear and accords with what PREMIS says on page 1-8 and with what we understand i.e. structural relationships are about how to put back together a digital object which consists of more than one part or file. However the paragraph under Derivation relationships on page 1-9 says "A structural relationship among objects can be established by an act of derivation before the objects were ingested by the repository ... " and "..They do not have derivation relationships with each other, but do have a structural relationship as siblings (children of a common parent)". It's confusing to describe this as a structural relationship because the 'siblings' are not part of the same digital object - they belong to different representations. "PARENT" AND "CHILD" On page 2-63 it says "is child of = the object is directly subordinate in a hierarchy to the related object ..." and "is parent of = the object is directly superior in a hierarchy to the related object ...", but it doesn't say what the hierarchy relates to. In the paragraph (on page 1-9) referred to above, "parent" refers to the object from which the "children" are derived, whereas on page 6-5 "children" is used to describe components of a web site. In the former case the parent has a "source of" relationship with the children; in the latter case the children have an "is part of" relationship with the (parent) website. In NLA's inhouse system (called Digital Collections Manager) the term "child" is used to denote "part of" at the Intellectual Entity level. Because "parent" and "child" can be used in various contexts, I'd like to suggest that the values "is parent of", "is child of", "has child" and "has parent" be avoided in relationshipSubType and that more precise terms such as "source of", "derived from", "is part of", "has part" be used instead. We will be looking more closely at controlled vocabularies for relationshipSubType and other PREMIS elements with this data constraint in the near future. Bronwyn Lee Australian Partnership for Sustainable Repositories http://www.apsr.edu.au National Library of Australia