DataCollection.abstract and DataCollection.concept_id should be attributes not methods

[andypbarrett]

earthaccess.results.DataCollection has abstract, concept_id, and attribute-type information as methods. I suggest that it is more intuitive that this information is stored as attributes.

In [31]: result = earthaccess.search_datasets(keyword="sea ice")

In [32]: len(result)
Out[32]: 780

cloud_hosted is an attribute, which seems intuitive.

In [33]: result[0].cloud_hosted
Out[33]: False

But concept_id, abstract, and summary are all methods are not. Trying to access them as an attribute dumps the entire DataCollection object because of missing the ().

In [34]: result[0].concept_id()
Out[34]: 'C2564625052-NSIDC_ECS'

I suggest, the intuitive access is

In[]: result[0].concept_id
Out[]: 'C2564625052-NSIDC_ECS'

[jhkennedy]

I agree, these would make more sense as attributes

[mfisher87]

💯

[asteiker]

@andypbarrett @jhkennedy @mfisher87 Do you consider this a good first issue? I wanted to confirm with you before adding it as a label. It seems fairly straightforward but I'm not sure if there are underlying complexities to changing these metadata elements to attributes.

[betolink]

@chuckwondo what do you think? I'm in favor of this, it will be a minor breaking change but they make more sense as attributes than methods.

[chuckwondo]

@chuckwondo what do you think? I'm in favor of this, it will be a minor breaking change but they make more sense as attributes than methods.

Yep, I agree!

[mfisher87]

I think there are other methods that can be decorated with @property while we're at it. It would be nice to do that all at once for consistency!

[chuckwondo]

I think there are other methods that can be decorated with @property while we're at it. It would be nice to do that all at once for consistency!

I agree. We should make the changes in one go.

[andypbarrett]

This has been resolved in #1187 but will be a breaking change. So will be merged for release of v1.0.0.