Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scientific extension: rel of cite-as links for sci:doi and for pub dois #915

Closed
schwehr opened this issue Nov 4, 2020 · 7 comments
Closed

Comments

@schwehr
Copy link
Contributor

schwehr commented Nov 4, 2020

This came up here stac-utils/pystac#199 (comment) where we are trying to implement the scientific extension in pystac.

It's difficult to distinguish the sci:doi link from the publication doi links. It feels weird that there is no way to distinguish the two types of links without lookin in the sci:doi field and pubs. What if the data doi and the publication doi are the same? What is someone adds a cite-as on their own?

{
  "sci:doi": "10.5061/dryad.s2v81.2",
  "sci:citation": "Vega GC, Pertierra LR, Olalla-Tárraga [SNIP]",
  "sci:publications": [
    {"doi": "10.1038/sdata.2017.78", "citation": "Vega GC, Pertierra LR, Olalla-Tárraga [SNIP]"}
  ],
  "links": [
    {"rel": "cite-as", "href": "https://doi.org/10.5061/dryad.s2v81.2"},
    {"rel": "cite-as", "href": "https://doi.org/10.1038/sdata.2017.78"}
  ]
}
@m-mohr
Copy link
Collaborator

m-mohr commented Nov 5, 2020

The links were just intended as simplification for clients and users, mostly for the ones not supporting the scientific extension so that user could still follow links. It was just meant as a list of related dois to follow, not to transport any additional information or so.
If two links would be the same, there should be just one link to it. The thing is that the DOI links can easily be generated if the client understands the sci extentsion/dois anyway so those clients don't really need the links.

@lossyrob
Copy link
Collaborator

The issue here isn't when the links are the same - it's when the links are different, and they are both labeled as 'cite-as'. 'cite-as' to me indicates - if you are going to cite this data, use this DOI. Which makes sense for the main "doi" field of the scientific extension.

However, for the publications, which are a "List of relevant publications referencing and describing the data.", the DOIs are not what users of the data should be citing. Therefore the "cite-as" link seems to be a misnomer here. The IEFT draft linked to in the relation type description in the extension spec is titled "cite-as: A Link Relation to Convey a Preferred URI for Referencing" - which the publication DOI links are not.

I'd recommend that the rel-type of the publication DOIs be changed from 'cite-as' to something else - perhaps 'publication-doi'? Happy to make a PR (in time) if folks agree this is a good change.

@m-mohr
Copy link
Collaborator

m-mohr commented Nov 19, 2020

Well, from my understanding the links are the preferred URIs for Referencing the publications. I had seen the links as addition to the individual sci:... entries and be used in that context, not just in the context of the metadata file. But your thinking also makes sense to me, but then it should be ensure that there's always a maximum of one cite-as, right? So either a new rel type would work or put the links into the publication object...

@lossyrob
Copy link
Collaborator

I think links in the publication objects would be odd, since it seems like "links" are the place for those. A new rel type would work, but another option is that we just have one cite-as and we don't give links to the referencing publications, because as you mentioned this is a convenience as users can figure that out for themselves, and the most important link is the cite-as.

Which option to people prefer? No links for publications, or links but with a new relation type? If the latter, does publication work, or are there other suggestions?

@m-mohr
Copy link
Collaborator

m-mohr commented Nov 23, 2020

I think both options are fine for me... Maybe go for simplicity and no links?

@matthewhanson
Copy link
Collaborator

I prefer the putting links in links and using specific rel types to define what it is. Additional sci fields in an extension would be used to provide additional context if needed.

lossyrob added a commit to lossyrob/stac-spec that referenced this issue Dec 11, 2020
Previous to this commit, the 'cite-as' rel type was used to describe
links to both the main publication for the dataset as well as any
publications citing the data as listed in the 'publications'
property. As discussed in radiantearth#915, this can cause confusion as to how the
data should be cited. This change specifies that only the main
publication descripting the data should have a link with 'cite-as' as
the rel type in the links section.

Fixes radiantearth#915
lossyrob added a commit to lossyrob/stac-spec that referenced this issue Dec 11, 2020
Previous to this commit, the 'cite-as' rel type was used to describe
links to both the main publication for the dataset as well as any
publications citing the data as listed in the 'publications'
property. As discussed in radiantearth#915, this can cause confusion as to how the
data should be cited. This change specifies that only the main
publication descripting the data should have a link with 'cite-as' as
the rel type in the links section.

Fixes radiantearth#915
lossyrob added a commit to lossyrob/stac-spec that referenced this issue Dec 11, 2020
Previous to this commit, the 'cite-as' rel type was used to describe
links to both the main publication for the dataset as well as any
publications citing the data as listed in the 'publications'
property. As discussed in radiantearth#915, this can cause confusion as to how the
data should be cited. This change specifies that only the main
publication descripting the data should have a link with 'cite-as' as
the rel type in the links section.

Fixes radiantearth#915
@lossyrob
Copy link
Collaborator

Closed with #931

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants