Adding codemeta.json file to content indexer
ClosedPublic
Actions

Authored by moranegg on Oct 16 2017, 3:17 PM.

Details

Reviewers

Commits

rDCIDXad74314ee453: Ammend metadata and added isPartOf relation to swh-env
rDCIDXb9ce4035fb13: Adding codemeta.json file to document metadata

Diff Detail

Repository

rDCIDX Metadata indexer

Branch

master

Lint

No Linters Available

Unit

No Unit Test Coverage

Build Status

Buildable 1054
Build 1389: arc lint + arc unit

Event Timeline

moranegg created this revision.Oct 16 2017, 3:17 PM

Harbormaster completed remote builds in B1052: Diff 852.Oct 16 2017, 3:55 PM

zack requested changes to this revision.Oct 17 2017, 11:26 AM

zack added a subscriber: zack.

zack added inline comments.

codemeta.json
20	Not sure what's the expected meaning of this URL, but it should either be the same of codeRepository, or the Software Heritage homepage, as we don't have a homepage for the specific indexer software component (yet). In no way it should be the GitHub URL though, which is just an accessory mirror of the main code repository.
21	do we really need this? it's a kinda low-level business detail that I don't think should have any part in advertised metadata about our software products, and that might change in the future
37	what's the point of this? as it's very uninformative, i suggest to remove it

This revision now requires changes to proceed.Oct 17 2017, 11:26 AM

zack retitled this revision from Adding codemeta.json file to document metadata to Adding codemeta.json file to swh-indexer.Oct 17 2017, 11:26 AM

zack retitled this revision from Adding codemeta.json file to swh-indexer to Adding codemeta.json file to content indexer.

Shouldn't we have a tool to update this regularly based on the different metadata we already have spread across the repository (setup.py, debian/control, debian/copyright, debian/changelog, git tag, etc...)?

codemeta.json
15	it works as is but `https://www.softwareheritage.org` sounds better :)
33	What's the difference with the "version" key?

In D255#5235, @ardumont wrote:

Shouldn't we have a tool to update this regularly based on the different metadata we already have spread across the repository (setup.py, debian/control, debian/copyright, debian/changelog, git tag, etc...)?

Nack, let's hardcode for now.
(yes, it'd be better in general, but it's not worth to work on that at this point)

(yes, it'd be better in general, but it's not worth to work on that at this point)

Oh yeah, i was aiming at middle/long term :)

moranegg added inline comments.Oct 17 2017, 3:27 PM

codemeta.json
15	agreed
20	Actually this url is the only url linking this revision to the origin on SWH we should want people to give the github url (even if it is a mirror) because with the github url we can find the whole tree in our archive. we can put both urls as url or as codeRepository. the github one serves better with our linked data challenge.
21	We don't need metadata- that's the point. The question is what do we want? This is an example to what we would like to find about other projects/software artifacts. About change in the future: this piece of metadata is about this revision and during the work on this revision, we had funding from the Inria. The problem might occur if we don't remove it when the funding is over. i don't mind deleting this entry.
33	you are right! I just submitted an issue with CodeMeta about it..
37	If we want to provide the persistent solution for software what do we provide? only the PID-sha1 in the id? the location of the revision in swh-archive? the location of the origin in swh-archive? The main question is, how do we want others to "use" SWH, here I thought to put it as a relatedLink but you are right it is wrong it should be in the identifier property or even more strict in a @id property. @id is used for DOI, ORCID, tec.. as resolvable URI. So i will remove it, but I think we should show how we want to be used and push our way in...

zack added inline comments.Oct 17 2017, 3:48 PM

codemeta.json
20	If that's the problem you're trying to fix, than the right fix is adding to the list of origins that we track the URLs of our repos—which would be a good thing in general (see T807 which I've just submitted). As I think we should neither promote our GitHub mirrors are privileged entry points for our code base, nor wait for T807 to be completed, please either drop it or use the phabricator repo URL here too.