SAA-SDT / eac-cpf-schema

https://eac.staatsbibliothek-berlin.de/
10 stars 4 forks source link

<relation> #214

Closed SJagodzinski closed 2 years ago

SJagodzinski commented 4 years ago

Relation

Creator of issue

  1. Silke Jagodzinski
  2. TS-EAS: EAC-CPF subgroup
  3. silkejagodzinski@gmail.com

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

Example encoding

<relations>
 <relation audience="external" conventionDeclarationReference="conventiondeclaration1" id="relation1" languageOfElement="en" maintenanceEventReference="maintenancevent1" scriptOfElement="lat" sourceReference="source1">
  <targetEntity targetType="person">
   <part>name or part of the name or term of the related entity</part>
  </targetEntity>
  <relationType>Family</relationType>
  <targetRole>Parent</targetRole>
  <dateSet>
   <date>1800</date>
   <dateRange>
    <fromDate>1900</fromDate>
    <toDate>1950</toDate>
   </dateRange>
  </dateSet>
  <place>
   <placeName>place of the relation</placeName>
   <placeRole>residence</placeRole>
   <date>1930</date>
   <descriptiveNote>
    <p>descriptive note to a place related with the target entity</p>
   </descriptiveNote>
  </place>
  <descriptiveNote>
   <p>note for this relation</p>
  </descriptiveNote>
  <objectXMLWrap>
   <anyelementofanynamespace/>
  </objectXMLWrap>
 </relation>
</relations>
ailie-s commented 3 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

fordmadox commented 3 years ago

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:

  1. targetEntity (1..1)
  2. relationType (0..N)
  3. targetRole (0..N)
  4. date | dateRange | dateSet | (0..1)
  5. place (0..N)
  6. objectXMLWrap (0..1)
  7. descriptiveNote (0..1)

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.).

kerstarno commented 3 years ago

@fordmadox - I like and support the approach you've mentioned above, i.e.

  1. required, not repeatable elements (possible prescribed order if there's more than one required, not repeatable element)
  2. required, repeatable elements (any order)
  3. optional, not repeatable elements (any order)
  4. optional, repeatable elements (any order)

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.

fordmadox commented 3 years ago

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.

karinbredenberg commented 3 years ago

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.