-
Notifications
You must be signed in to change notification settings - Fork 47
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
Change dc:creator to dcterms:contributor #731
Conversation
@matentzn @cthoyt @anitacaron the qc is failing b/c of non-conforming values for the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like some xsd:dateTime
datatypes were lost. Also a bunch of xsd:string
s, but that doesn't matter—was it on purpose?
How does this relate to 'has roost'? It seems like a general cleanup.
@balhoff when I changed the annotation property I didn't specify the datatype. I assumed the datatype would carry over to the new annotation. My mistake :( This PR originated from my oversight of merging NTR: has roost prior to the qc checks finishing :( |
@wdduncan Mind if I commit directly to this PR to fix the remaining QC issues? |
@gouttegd I don't mind at all! |
Done and the CI checks now pass. |
Please please please do not merge this until the commit history on the main branch is fixed |
What needs to be fixed? I'm not following. |
@cthoyt The point of this PR is precisely to fix the breakage that was introduced by the merging of #672. I agree that a hard reset to cancel #672 would be cleaner, but not now that the merge has occurred on the public master branch. Hard resets are good on a local repository to cancel commits that have never been published, but once they have been pushed on a public repo, it’s too late. Rewriting history on a public branch is a bad idea. |
please see #732. @gouttegd either way, can you help remove all of the spurious diff in this PR? like tons of changes are totally irrelevant to the content update I'm not sure I agree about rewriting history on a public branch. This only happened a day ago and I don't think that changing it will affect anyone who isn't already involved in PRs on this repo anyway |
@cthoyt Those “spurious changes” are not irrelevant: they are here to fix the real spurious changes that were introduced in #672. Obviously, when you introduced a spurious change, the fix to it also looks like a spurious change. Note that if you go the #732 route and reset the main branch to before #672 was merged, then this PR becomes irrelevant, so I don’t know why your last item in the description of #732 is to ”fix #731”. (I am personally opposed to any form of history re-writing on a public repo. That being said, I don’t know what is the OBO policy on the matter – if even there is one –, so if nobody else has a problem with that, I won’t object |
That is what is most important. Github purity is secondary to do this. |
#672 was merged 3 days ago. Hard-resetting the master branch to before it was merged will affect anyone who has updated their local copy since then. That’s reason enough for not doing so, in my opinion. |
Declaration(Class(obo:CARO_0000000)) | ||
Declaration(Class(obo:CARO_0000003)) | ||
Declaration(Class(obo:CARO_0000006)) | ||
Declaration(Class(obo:CARO_0000007)) | ||
Declaration(Class(obo:CARO_0001001)) | ||
Declaration(Class(obo:CARO_0001010)) | ||
Declaration(Class(obo:CARO_0010000)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still, have to redo some changes! No CARO is imported anymore.
No description provided.