hi everyone,
this is probably a bit heretical at its heart because the fact that one has adopted a metadata model (DDI) presumes that the relationships between the fields are arranged formally; it may be heretical to suggest that one use the fields any other way.
the problem i have concerns the "original publication" metadata for a study. In the current implementation of the DVN fields has no explicit location for that originating document's URI.
I'll hold off on my use case where there is no original publication but the simple use case I want to implement today is where a Study's record is harvested via OAI-PMH and from this record I can pair original/related publication(s) URI with the study's / dataset URI. The harvester is another non-Dataverse repository that wants to index the studies' and attach them to bibliographic records.
As far as i can tell there is only the HTML accepting, "Original Publication" field, which enforces no clear structure on the input. This is also true of related publications -- its just HTML, no structure that enforces a clear ID encoding. Asking my OAI-PMH harvester to parse this HTML involves unnecessary ambiguity IMHO (an in the humble opinion of the harvester as well).
On the other hand, the "Other ID" field clearly creates a machine interpretable field where I can input a namespace and a URI; in fact I can list a whole set of these. What I am tempted to do is to reuse the Other ID field to contain all the URIs that pairwise mate to the data in the study. That was the heretical part as I doubt it was what this field was intended to do.
I guess what I want is to discuss with both other users and dev how they deal with the softness of the original and related publications fields. Is their current HTML formatting so important for presentation? only? For me the ultimate implementation of the fields would be web service calls to URIs to ingest the relevant connected publication metadata; this could be converted via a stylesheet to as purty an HTML as one might like.
Best,
- Gus