There’s currently no narrative element as part of the ‘related-activity’ element http://iatistandard.org/202/activity-standard/iati-activities/iati-activity/related-activity/
Propose that this is added as part of 2.03 upgrade. Further background here https://github.com/devinit/D-Portal/issues/332
Comments (4)
I have a basic question!
Is it definitely a good idea to violate the ‘don’t repeat yourself’ principle like this? It increases redundancy and therefore file size, and I guess there are other potential syncing issues. I suppose there’s a perceived trade-off here between duplication and making the data easy to use?
As an example, I’ve had a go at doing this for the activity mentioned in the github issue. Here’s the original activity… And here it is with related-activity titles embedded (fetched from the IATI datastore). Massive!
In the short-term, this wouldn’t solve the issue seen in d-portal anyway, because publishers may not upgrade to 2.03 immediately.
I’d agree with Andy Lulham
Scenario: what happens if one publisher gives the title for a related activity, but it is different from that given in the actual activity (either by a third party or by the publisher themselves)? This might cause headaches for the data user.
For applications such as d-portal, it seems possible to go and fetch the title of the related activity, and print that on screen. I think that’s where this github issue was heading, following some work to start linking up references to other transactions and organisations
Agree with Steven Flower and Andy Lulham that including a title in this manner would lead to DRY problems and so a related-activity/narrative element should not be used to contain information that the related activity provides itself.
Could a narrative element in this location instead provide useful information to clarify result-type/@type? For example:
<related-activity ref="AA-AAA-123456789-6789" type="3"> <narrative>An equivalent project, being implemented in Kenya rather than Tanzania.</narrative> </related-activity>
Again, there could be DRY problems (parents and children providing the same information in different directions). I’m not, however, immediately aware of anywhere in the Standard that this information can currently be represented (unlike titles, which can be extracted directly from the related activity).
Note: I’ve not looked at whether this data would be either useful, or available in practice.
Please log in or sign up to comment.
+1 this is a good example of a potential syncing issue. This could be caused by a change to an activity title (IATI IDs may be immutable, but titles are not!) Keeping activity data in sync when it potentially spans multiple files and even multiple publishers introduces significant complexity.
Bit off-topic, but… I think that second example is fundamentally different, because the information required is all available in the XML without extra requests.