Study Level Error Notes field maps in DDI to "anylInfo" instead of "anlyInfo"

[BPeuch]

Version: 2.19

In the "Social Sciences and Humanities Metadata" block, the content of the field "Study Level Error Notes" is transferred into an erroneously spelled <anylinfo> element in DDI instead of <anlyInfo>.

This could also be worth mentioning in the crosswalk spreadsheet (where it is also rightly stated that anlyInfo does not allow character data).

See this DDI output for a Dataverse metadata record where the content of all fields is the fields' labels:

anylinfo.txt

[jggautier]

Hi @BPeuch! This is addressed in the PR #6669 being worked on as part of a dataset migration effort. One of the many things the PR does is remove that <anylinfo> element and map Study Level Error Notes to a <notes> element directly below <stdyDscr>:

<codeBook ...>
        ...
	<stdyDscr>
		...
		<notes>StudyLevelErrorNotes</notes>
	</stdyDscr>
	...
</codebook>

And on import the contents of that element are mapped back to the Study Level Error Notes field.

In the broader issue about the DDI export following the schema, #3648, I recommend including an attribute, like <notes type="Study Level Error Notes">Study Level Error Notes</notes> (or maybe a "level" attribute should be used, hmmm).

But for now I think the solution in the PR I mentioned works since the only other "notes" metadata field, labelled "Notes" in the citation metadata block, is placed in a <notes> element directly below the <stdyInfo> element, making it easy to map the right Dataverse "notes" fields to the right DDI "notes" elements on import and export.

An example DDI export from that PR is at http://ec2-52-87-250-239.compute-1.amazonaws.com/api/datasets/export?exporter=ddi&persistentId=doi%3A10.5072/FK2/FPWD9T. The PR's being worked on, so that example won't reflect some of the most recent changes. When it's merged, I plan to update the crosswalk. Thanks for referring to it!

Could you share how/why you noticed this error in the DDI export? I'm curious :)

[BPeuch]

Hello @jggautier. Thanks a lot for your comprehensive feedback!

I couldn't find mention of this problem in the issues on GitHub or the threads on the Google group, but I forgot to check the pull requests. My bad. (Still getting around to mastering GitHub. But the support of the IQSS team is greatly appreciated.)

I agree with utilizing the type attribute of XML elements in such cases. I try to do it as often as I can when I'm working with Encoded Archival Description (XML-EAD).

And I've been mapping this latter XML standard—which is used for encoding digital finding aids and making them machine-actionable—to DDI because I work at the State Archives of Belgium and EAD is the norm in the world of archives. For that reason I wanted to check how Dataverse produces DDI and so, just like you with this DDI export you linked to, I filled in the fields with their labels to lay out the correspondences.

Because our project at the State Archives consists in becoming the national CESSDA endpoint for data and metadata in social sciences, we have to juggle between Dataverse's metadata (native + custom subset, thanks to Dataverse's modularity), their DDI output, CESSDA's mandatory metadata (the CESSDA Core Metadata Model), the specific subset thereof to make our records harvestable by the CESSDA Data Catalogue (a European-level, OAI-PMH-powered portal) and, finally, the State Archives' native system, which revolves around EAD.

So that's why I've been peering into Dataverse's DDI outputs like an old, bespectacled historian using a looking glass, haha.

Good luck with the overhaul of Dataverse's DDI export!

[jggautier]

And thanks for your comprehensive answer. That's a lot of juggling for an old, bespectacled historian! Please feel free to keep opening issues or leave comments on that Dataverse crosswalk spreadsheet if you find other areas for improvement.

I'll close this issue since it's being addressed in another.