Enhancement of complexType relation

[lundst1]

This is a suggestion to add an attribute name to the complexType relation. Having a name for the relation would simplify recreating a link between aggregations (from the source system). It would also enable storing some free text information about the relation, allowing for usage of any relationType value other than "own_relation_definition".

[karinbredenberg]

Thank you for your suggestion. we will look into it.

[karinbredenberg]

Reading through your suggestion again.

When you set the value of attribute relationType to "own_relation_definition" you are through the provided Schematron aided with fulfilling the requirement ERMS54 where the use of the attribute otherRelationType is to be used in that case and give the information needed. Information that can be of what decided upon to be used since handling it will require an agreement to be able to be processed.

Do I understand you correctly that you want be able to use the predefined value list and then also provide more information about the relation? What can this extra information be? How is the extra information connected with the new attribute named name of the relation you suggest since name and information is not the same thing? Could you please provide more examples on what type of data you want to encode in the relation?! If possible screens shots will aid in understand your use case for the suggestion.

[lundst1]

At the moment i cannot provide screenshots, however i can describe the use case further.

Every aggregation and its' children is displayed as a web page, via the use of XSLT. For every relation i want to produce a standard HTML link, ie:

<a href="..">..</a>

The source from which i migrating cases store links between cases in a table containing source key, goal key, name, and description. Both name and description are contain text based values. However, users inform me that both values are generated through some pre-configured rule. Users can edit these values before saving. The value name, in the table, seems to be more specific to the specific link. The value description seems to be some standardised elaboration.

Adding an element name allows me to display a human readable name to the user, which i think would be prudent for other use cases than mine. More importantly, it allows me to retain the name information from the source, while also allowing me to retain the description information by encoding it to the element "own_relation_definition".

[karinbredenberg]

Thanks for your added explanation.

To further understand it, please provide example values of the pairs of name and description.

[lundst1]

Absolutely! Currently OOO, but will provide examples next week.

[lundst1]

Here are some examples. The source system is the case management system W3D3, and the examples are in swedish. I'm assuming that this won't be an issue, since you are swedish.

Here you see a common standardised name description pairing for a case that references a case from which it was copied. The user has copied the case for some reason and the system has generated a name containing the original cases case number and the word for original case. Description explains this further.

Name	Description
LÄR 2010/25_originalärende	Originalärendet som detta ärende är kopierat från.

In the example above, one could argue that the current specification would suffice. However there are also non standardised occurrences.

Name	Description
Kopplat till annat ärende	LÄR 2008/69

Here the user has placed a describing text in the name field and the name of the referenced case in the description field.

Name	Description
LÄR 2011/84	Projektet Min Kropp har lyfts ur Lär 2010/105 eftersom det är ett eget ärende

Here name contains the referenced cases case number and description a user defined description.

As you can see i cannot safely write neither Name nor Description to the text content of an element relation, if i want to be able to genererate a functioning link to another file. I also want to retain information from both fields.

[karinbredenberg]

Thank you for adding the value pairs you have! Yes, Swedish works for me but lets keep the conversation in English so all can understand the discussion.

The problem as I see it is that the users of the system haven't been consistent in adding their information due to the software allowing all types of information to be entered. I assume you have an UUID, GUID or some other identifier from the database added as an ID in the XML-document to use as the value of the relation as well and not just a case number in either the name or description.

Knowing Swedish I see that all three examples are using values from the supplied value list even if some mapping of sentences and not just keywords needs to be made.

Adding the attribute you suggest will not solve the problem you have, and will introduce other problems of inconsistency to the specification in regards to how names and descriptions are used through out the specification where they have specific meanings. I assume that you as the link text want to concatenate the name and the description. If you look at the specification no descriptions appears as attributes they are textual elements. Adding an element to the specification in the relation element will not be a small fix, it will introduce a new element to give the related ID of the case/record and addition of the note element for the description to not introduce mixed content. This will not be backwards compatible and demanding a major release.

A reminder is that you for this type of user specific use case of the specification also can utilize the use of the possibility to add your own elements not being in the CITS where you can structure this information as you need them to be able to easily make your additions of the information to the relation and simplify your creation of an link to the other case/record.

Being in Sweden I also need to remind you that you also need to look at the instructions from the National Archives regarding the use of CITS ERMS, https://www.riksarkivet.se/Media/pdf-filer/doi-t/Riksarkivets_tillampning_av_E-ARK_CSIP_och_SIP_V1.0.pdf .

My response to the suggestion is that this will be a feature request that needs to get more supporters before its being introduced and moves the specification to its next major version.