Closed SJagodzinski closed 2 years ago
Tag Library Text:
Summary: A required child element of <relations>
for describing a relationship between the entity described in the EAC-CPF instance and a related entity.
May contain: date or dateRange or dateSet (0..1), descriptiveNote (0..1), objectXMLWrap (0..1), place (0..n), relationType (0..n), targetEntity (1..1), targetRole (0..n)
May occur within: relations
Attributes:
@audience
- optional (values limited to: external, internal)
@conventationDeclarationReference
- optional
@id
- optional
@languageOfElement
- optional
@maintenanceEventReference
- optional
@scriptOfElement
- optional
@sourceReference
- optional
@target
- optional
Description and Usage:
<relation>
records descriptive information about a relationship between the entity being described and a related entity, such as: a corporate body, person, or family; a function; or an archival, bibliographic, or other resource.
Use the required child element<targetEntity>
to provide a textual description of the related entity. Use the optional child element <relationType>
to specify the type of relation. Use the optional child element <targetRole>
to specify the role of the related entity.
Use <objectXMLWrap>
to embed XML documenting the related entity from any namespace other than EAC-CPF. Use <date>
, <dateRange>
, or <dateSet>
for specifying the time period of the relationship and <place>
for relevant location information. <descriptiveNote>
may be included for more detailed specifications or explanations of the relationship.
Availability: Required, repeatable
Since this element is mixing the availability of its children elements, is there a preferred order for how they elements should appear? Right now, that order is defined as:
Right now, I like the approach of going with something like: 1) required, but not repeatable elements; 2), required, repeatable elements (possibly in any order); 3) optional, but not repeatable elements (possibly in any order), and 4) optional, repeatable elements (possibly in any order). But, doing that would change where elements like descriptiveNote
and objectXMLWrap
can occur, so maybe better to switch that around a bit? Or, we could continue with how things are done in EAC 1.0, and just worry about whatever order we think makes the most sense for each element (e.g. control can have a completely different ordering from description, vs. cpfDescription, etc.).
@fordmadox - I like and support the approach you've mentioned above, i.e.
As Silke mentioned in another issue, maybe we could have this question on the agenda for the Schema team meeting next week? Might be good to have some additional examples of elements with their sub-elements following this approach to see whether it makes sense in the various contexts. Happy to select some examples from EAC-CPF as well as from EAD3 for comparison, if you want me to.
Sounds good to me, thanks, @kerstarno!
I'll add it to agenda for the Schema team's January meeting so that we can discuss about possibly adding such a formulation to our design principles.
Test of element relation: May contain: date or dateRange or dateSet (0..1), Ok in both schemas descriptiveNote (0..1), Ok in both schemas objectXMLWrap (0..1), Ok in both schemas place (0..n), Ok in both schemas relationType (0..n), Ok in both schemas targetEntity (1..1), Ok in both schemas targetRole (0..n) Ok in both schemas May occur within: relations 1..n Ok in both schemas Attributes: @audience - optional (values limited to: external, internal) Ok in both schemas @conventationDeclarationReference - optional Ok in both schemas @id - optional Ok in both schemas @languageOfElement - optional Ok in both schemas @maintenanceEventReference - optional Ok in both schemas @scriptOfElement - optional Ok in both schemas @sourceReference - optional Ok in both schemas @target - optional Ok in both schemas
Result: element ready.
Relation
<relation>
as child element of<relations>
<targetEntity>
<relationType>
,<targetRole>
<date>
,<dateRange>
,<dateSet>
,<descriptiveNote>
,<place>
@audience
@conventationDeclarationReference
@id
@languageOfElement
@maintenanceEventReference
@scriptOfElement
@sourceReference
Creator of issue
Related issues / documents
Paper on Relation
EAD3 Reconciliation
May contain: daterange, dateset, datesingle, descriptivenote, objectxmlwrap, geogname, relationentry Attributes:
@actuate
,@altrender
,@arcrole
,@audience
,@encodinganalog
,@href
,@id
,@lang
,@lastdatetimeverified
,@linkrole
,@linktitle
,@otherrelationtype
,@relationtype
,@script
,@show
Context
new EAC-CPF element
Solution documentation:
Summary, Description and Usage and Attribute usage needed
May contain:
<date>
,<dateRange>
,<dateSet>
,<descriptiveNote>
,<objectXMLWrap>
(0..1),<place>
,<relationType>
(0..n),<targetEntity>
(1..1),<targetRole>
(0..n) May occur within:<relations>
Attributes:@audience
- optional (values limited to: external, internal)@conventationDeclarationReference
- optional@id
- optional@languageOfElement
- optional@maintenanceEventReference
- optional@scriptOfElement
- optional@sourceReference
- optionalExample encoding