How can codemeta increase discoverability by Google?

(copying this question over from another issue thread by @maelle. We ought to get this hashed out a bit better and then could maybe address this directly on https://codemeta.github.io)

Google uses and encourages the use of JSON-LD markup using the schema.org terms: https://developers.google.com/search/docs/guides/intro-structured-data . This focuses on ‘rich card’ results shown on primarily on mobile devices, but applies to search generally.

At the moment, just adding a codemeta.json file to a github repo probably won’t do anything to Google search since it’s not embedded into an html file. If we embedded into, say, html version of the README page CRAN generates, or into a pkgdown-generated site for a package, since then it would be crawled by Google. There’s currently no rich card format for software, but the use of rich markup may still increase search rank.

(Google aside, the hope is also that this improves search in specific repositories that adopt or learn to read codemeta, such as Datacite: https://search.datacite.org/works?query=Software or http://citeas.org/ , Software Heritage, Zenodo, DataONE).

[danbri]

Yes, what Carl says: it checks that Google can understand the dialects of json-ld understood by 25-30 or so Google product features

On Fri, 22 Nov 2019, 00:49 Carl Boettiger, [e-mail] wrote:

@danbri https://github.com/danbri can probably elaborate further, but I believe Google’s structured data testing tool is not intended to be a generic validator of the W3C JSON-LD specification, but rather, whether the JSON-LD conforms to Google’s specific use cases.

That said, I think just going with @context: “http://schema.org” makes sense to me in this case. It doesn’t look like you have any terms that aren’t already schema.org terms, so I think either way should be considered to be a valid codemeta file. Furthering the already close alignment between CodeMeta and schema.org vocabularies would improve interoperability overall anyway.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/codemeta/codemeta/issues/179?email_source=notifications&email_token=AABJSGJOPO7MLQMNHSO3STDQU4NAHA5CNFSM4EJJTAOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE4BO2Y#issuecomment-557324139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGPYANMTQW4KLMQKZRLQU4NAHANCNFSM4EJJTAOA .

[cboettig]

@danbri can probably elaborate further, but I believe Google’s structured data testing tool is not intended to be a generic validator of the W3C JSON-LD specification, but rather, whether the JSON-LD conforms to Google’s specific use cases.

That said, I think just going with @context: "http://schema.org" makes sense to me in this case. It doesn’t look like you have any terms that aren’t already schema.org terms, so I think either way should be considered to be a valid codemeta file. Furthering the already close alignment between CodeMeta and schema.org vocabularies would improve interoperability overall anyway.