change in "Show Contents of a Dataverse" endpoint of Native API

[felliott]

Hello!

This is a crosspost of IQSS/dataverse-client-python#50 since I don't know if this was an intentional change or not. The python library expects that the objects returned from this endpoint will have protocol, authority, and identifier properties. Recently the OSF has started seeing errors due to receiving objects like the following:

{u'id': 1781, u'title': u'Carl Klarner Dataverse', u'type': u'dataverse'}

Does the library need to be updated to accommodate these, or is this a regression in the API? Thank you very much!

Cheers,
@felliott

[pdurbin]

@felliott hi! I sure hope we didn't introduce a backward compatible change. Can you please test against the following installations of Dataverse?

• Dataverse 4.8.6: https://dataverse.lib.virginia.edu
• Dataverse 4.10.1: https://dataverse.harvard.edu

[landreev]

This is intentional, and I'm pretty sure this has always been the behavior of the API.
The API lists "all the DvObjects" in a dataverse; where a DvObject can be either a dataset, or another dataverse.
Dataset entries (type="dataset") will have the protocol, authority and identifier attributes. Sub-dataverses (type="dataverse") will not have these attributes, because dataverses don't have global identifiers. (but they will have the "title" attribute)
The type value unambiguously identifies which format to expect.

[felliott]

@pdurbin, our logs show one error against the Harvard DV and one against demo. We have others that are working fine, so maybe it has something to do with the content of the particular dataverse they're trying to connect to? @landreev's comment makes me think that maybe we just haven't encountered the dataverse-within-a-dataverse case yet, especially since the code in the library returns once the dataset is found. That would mean that this would only be triggered if a Dataverse DvObject was encountered before a Dataset DvObject.

@landreev, are the possible types for DvObjects documented anywhere? I searched the NativeAPI docs for DvObject but didn't find anything.

Cheers,
@felliott

[landreev]

@felliott (and everybody):
I was already thinking that we should definitely include some examples of the output, of this and other similar API methods in that guide; I mentioned it to other people here earlier.
The whole idea of a DvObject - that it can be either a Dataverse, or a Dataset or a Datafile; and that dataverses can contain both datasets and other dataverses... but not datafiles - which can only occur in datasets - these are all pretty core ideas behind our application... so we may have never thought of explaining it in the API guide all that clearly. (although it may be explained in other guides).

We should definitely take a good look at the API guide, now that more people who are not necessarily part of the immediate Dataverse community are using it; and make sure things like that are more clear.
(but including more examples showing the expected format of the output should by itself help a lot)

[pdurbin]

Pull request IQSS/dataverse-client-python#51 was just made by @pattisdr from @CenterForOpenScience so I'm dragging this issue to code review at https://waffle.io/IQSS/dataverse

[landreev]

I have approved that PR, in the dataverse-client-python project; it actually makes perfect sense as is.
What do we do with this issue - just close it, or what? OK, let's figure it out on Mon.

[pdurbin]

We should merge IQSS/dataverse-client-python#51 before closing this issue but yes, let's discuss Monday.

[landreev]

So who does the merging of PRs in dataverse-client-python? (@pdurbin? Or is somebody else in charge of maintaining that project now?)

[landreev]

OK, it's been merged - thanks @djbrooke.
@kcondon - I'm assuming we just close this issue, because there are no changes/nothing to qa on the dataverse side...
But I'm moving it for you to decide.

[djbrooke]

I merged the PR. I'll close this issue.

[landreev]

OK, even better :)